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Applicants, Assignee, and the undersigned agree that Kitai leaches LANs, but we disagree 
with the Examiner's position on the implications of LANs in Kitai. In particular, wc submit lhat 
it does not matter whether Kitai teaches LANs, because LANs are not private networks. 

It is uncontested that Kitai fails to teach frame relay or point-to-point networks; LANs arc 
the only candidates for private networks in Kitai asserted by the Examiner. Thus, the pending 
rejections rely on the Examiner's assertion that Kitai teaches private networks by teaching LANs. 
Because LANs are not private networks, the rejections based on Kitai arc improper and should be 
withdrawn or reversed. 

As promised by the undersigned during the interview, arguments are provided below to 
more fully explain and show why "private networks" do not include LANs. 

The meaning of "private networks" depends on the specification, and on skill in the art 

The term "private network" was coined for use in the present application - its first 
appearance in the body of the specification is in quotes. It is an exercise of the well-established 
right of patent applicants to be their own lexicographers. Accordingly, the specification must be 
considered when determining what is and what is not meant by "private network". See M.P.E.P. 
§2111 (PTO gives claims their broadest reasonable meaning while "taking into account 
whatever enlightenment by way of definitions or otherwise that may be afforded by the written 
description contained in applicant's specification"). "Private network" cannot be given any 
meaning whatsoever - it can only be given a meaning that is consistent with the examples and 
discussion in the application. 

The application gives examples of private networks, e.g., frame relay networks and/or 
point-to-point networks. The application does not state that a LAN is a private network; if it did, 
the Examiner's interpretation would be correct. 

On the other hand, the application docs not contain an express contrary statement such as 
"a LAN i s not a private network". The usefulness of such a statement was not apparent during 
preparation of the application, Tt simply did not occur to the undersigned while preparing the 
application that someone might read ''private network" to include LANs. 
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In short, the broadest reasonable interpretation of the claims must be consistent both with 
the specification and with the interpretation that those skilled in the art would reach. M.P.E.P. § 
2111. We therefore face the question of how the term "private network" would be understood by 
one of skill in the art who read the application to gather the intended meaning of that term. 

A person of skill understands: LANs are not WANs, and frame relay implies a WAN 

A person of skill in the art would understand certain things even before reading the 
application. For instance, one skilled in the art would understand the following definitions, or 
similar definitions; 

LAN (n.) Local area network, a network of multiple interconnected data terminals or 
devices within a local area to facilitate data transfer. Most notable of LAN topologies is 
ethernet, token ring, FDDI, etc. 

WAN (n.) Wide area network, a network of circuits spanning a large region or global in 
proportions, that is used to transmit data between widespread subscribers. See also LAN. 

FRAD (n.) Frame relay assembler/disassembler, used to interface a LAN with a frame 
relay WAN. 

"High Performance Computing and Communications Glossary 2.1" (1993, 1995) (at 
http://wotug.ukc.ac .uk/parallel/acronyms/hpccgloss) 

Likewise, one of skill would understand that the differences between LANs and WANs 

go beyond the differences in their geographic scope. For instance, one skilled in the art would 

have an understanding of the following passage: 

Remote bridging presents several unique internetworking challenges, one of which is the 
difference between LAN and WAN speeds. Although several fast WAN technologies 
now are establishing a presence in geographically dispersed internetworks, LAN speeds 
arc often an order of magnitude faster than WAN speeds. Vast differences in LAN and 
WAN speeds can prevent users from running delay-sensitive LAN applications over the 
WAN. 

"What is Bridging?" (Cisco Systems; copyright 2000) (at 
http://www.pul.^wan.com/datal0^ridging_basics.htm) (emphasis added) 

One of skill would also associate frame relay with WANs, not with LANs. This is cJear 
from the definition of FRAD above. It is also apparent in the puzzled question "J low would 
there be Frame Relay in a LAN environment?" in the following posting: 
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Re: Encapsulation for LAN emulation 

• From: comp.dcom.cell-relay@wscnet.ucs.indiarfa.edu 

• Dale: Thu, 5 May 1994 17:53:59 -0500 

• X-Originally-Ftom: rajeev@trillium.com 

V. Srinivas writes, 

> Is there any move towards providing LAN emulation on the Frame ftel 

> ATM .mtterworking scenario also ? 

LAN Emulation is currently being defined for IEEE 802.3 and 802.5 
only. 1 don't understand the "LAN emulation on the Frame Relay ATM 
mtterworking scenario". How would there be Frame Relay in a LAN 
environment? Of course if LAN Emulation is carried over an ATM 
network that interworks with a Frame Relay network to provide 
end-to-end connectivity, then sure your scenario exists, but that 
is transparent to LAN Emulation. 



RaDeey Gupta Email . rajeev@trillium.com 

Trillium Digital Systems, Inc. Voice (w) : (310) 479-0500 

2001 S. Harrington Ave., Suite 215 Fax (w) : (310) 575-0172 
Los Angeles, CA 90025. 

(at http : //cell-rolay . Indiana . edu/rohonarc/cell-relay/1994-Mdy/msgOOO 91 . htna ) 

The definitions, article excerpt, and posting provided above are not comprehensive, but 
the undersigned believes they are representative of how one of skill would understand the 
relationship between LANs, WANs, and frame relay before reading the application. This 
includes the understandings that (a) LANs and WANs are not readily interchangeable, and (b) 
frame relay is associated with WANs as opposed to WANs. 

The application's "private networks" would be understood as WANs, not LANs 

As explained in the Response filed February 4, 2004, "private networks" are defined and 
exemplified in the application to include frame relay networks and/or point-to-point networks. 
As noted above, one of skill would not expect to find frame relay in a LAN, and would instead 
associate frame relay with WANs. Since the application does not suggest otherwise, one of skill 
would therefore understand private networks to be WANs rather than LANs. 

Moreover, the text and figures of the application treat a private network as something that 
connects local and remote sites; page 13 refers to demote sites" and "distant networks". LANs 
are local area networks, whereas WANs are wide area networks spanning large regions. One of 
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